The HL7-OMG Healthcare Services Specification Project: Motivation, Methodology, and Deliverables for Enabling a Semantically Interoperable Service-oriented Architecture for Healthcare

Objective: To develop a replicable, collaborative framework for standardizing the interfaces of software services important to healthcare. Design: Iterative, peer-reviewed development of a framework for generating interoperable service specifications that build on existing and ongoing standardization efforts. The framework was created under the auspices of the Healthcare Services Specification Project (HSSP), which was initiated in 2005 as a joint initiative between Health Level7 (HL7) and the Object Management Group (OMG). In this framework, known as the HSSP Service Specification Framework, HL7 identifies candidates for service standardization and defines normative Service Functional Models (SFMs) that specify the capabilities and conformance criteria for these services. OMG then uses these SFMs to generate technical service specifications as well as reference implementations. Measurements: The ability of the framework to support the creation of multiple, interoperable service specifications useful for healthcare. Results: Functional specifications have been defined through HL7 for four services: the Decision Support Service; the Entity Identification Service; the Clinical Research Filtered Query Service; and the Retrieve, Locate, and Update Service. Technical specifications and commercial implementations have been developed for two of these services within OMG. Furthermore, three additional functional specifications are being developed through HL7. Conclusions: The HSSP Service Specification Framework provides a replicable and collaborative approach to defining standardized service specifications for healthcare. J Am Med Inform Assoc. 2009;16:874–881. DOI 10.1197/jamia.M3123. y gest on Jauary 5, 2016 Introduction In recent years, enterprises across various industries have begun to realign their information technology (IT) assets around a service-oriented architecture (SOA), in which busiAffiliations of the authors: Division of Clinical Informatics, Department of Community and Family Medicine (KK), Institute for Genome Sciences & Policy (KK), Duke University, Durham, NC; SOA Architect, Walnut Creek, CA (AH); Federal Healthcare Portfolio, Electronic Data Systems, An HP Company, Bowie, MD (KR). KK’s effort on HSSP and related projects has been supported by National Institute of Health grants T32-GM07171, F37-LM008161, K01-HG004645, R41-LM009051, and R42-LM009051; Agency for Healthcare Research and Quality grants R01-HS10472, R01-HS015057, and R03-HS10814; and Health Resources and Services Administration grant H2ATH00998. The other authors’ efforts were supported by their employers [KR–EDS, an HP Company; AH—Kaiser Permanente until 2008; currently an independent consultant contracted to the International Institute for Safety in Medicine (II4SM)]. All authors contributed to the conception and design of the manuscript, and KK drafted the manuscript. All authors contributed to the critical revision of the manuscript. The authors are members of HL7 and OMG. KR is co-chair of the OMG Healthcare Domain Task Force. AH and KR are or have been co-chairs of the HL7 SOA Working Group. KK is the project lead of the HL7 Decision Support Service project, AH was the main author of the HL7 EIS SFM, KR was the main author of the SSF, and all authors were coauthors of the HL7 RLUS SFM. ness needs are fulfilled through the orchestration of platformneutral, network-accessible software services that provide core business functions through well-defined interfaces. The use of SOA within healthcare could produce significant benefits, KK holds intellectual property rights to a CDS technology known as SEBASTIAN that can provide its capabilities through an HSSP Decision Support Service interface. These intellectual property rights are held in a holding company known as Kedasys, LLC, and the technology has been licensed to Religent, Inc. for commercialization through the assistance of Small Business Technology Transfer grants R41-LM009051 and R42-LM009051 from the National Library of Medicine. KK and Duke University may benefit financially if products using the SEBASTIAN technology are commercially successful. Of note, the OMG process requires that any intellectual property required for implementing to the interface standards are made available to others for free or on nondiscriminatory and commercially reasonable terms. The views expressed in this manuscript are those of the authors alone and do not necessarily reflect the official opinions of the organizations with which the authors are affiliated. Correspondence: Kensaku Kawamoto, M.D., Ph.D., Division of Clinical Informatics, DUMC Box 104007, Durham, NC 27710; e-mail: [email protected] . Received for review: 12/30/08; accepted for publication: 08/12/09. Journal of the American Medical Informatics Association Volume 16 Number 6 November / December 2009 875 by gest on Jauary 5, 2016 ht://jam ia.oxfournals.org/ D ow nladed from including improved reuse of existing IT assets and an enhanced ability to respond to new business needs in a timely manner. To fully achieve these benefits, however, healthcare organizations and health IT vendors will need to adopt standard service interfaces that encompass both common capabilities and common semantics, as SOA does not inherently support standard interfaces. Such standardization is critical because healthcare organizations often use a multitude of health IT systems developed by different vendors, and because patient care must often be coordinated across organizations. To address this need, Health Level 7® (HL7; Ann Arbor, MI) and the Object Management Group® (OMG; Needham, MA) launched a joint initiative in 2005 to define standard software services important to healthcare. Health Level 7 is the leading standards development organization in health IT internationally, whereas OMG is an open-membership computer industry consortium with expertise in developing enterprise interoperability standards in general, and software service standards in particular. Through this initiative, known as the Healthcare Services Specification Project (HSSP), various healthcare stakeholders have collaborated to generate a comprehensive framework for the specification of standard service interfaces. Known as the HSSP Service Specification Framework (SSF), this framework has been used to generate several service specifications that have been adopted as HL7 and OMG standards. In this manuscript, we (i) describe the SSF; (ii) outline how the SSF has been used to specify two HSSP services; and (iii) discuss implications and future directions. These perspectives are based on the authors’ experience establishing HSSP (KR and AH), co-chairing responsible committees within HL7 and OMG (KR and AH), and serving as principal contributors to HSSP service specifications (AH and KK). Healthcare Services Specification Project (HSSP): Vision and Design Principles HSSP Vision The HSSP vision is to enable the use of standard SOA services in healthcare by (i) developing standard service interfaces and (ii) providing guidance on how to leverage these services within a SOA. Three types of services are candidates for standardization: (i) infrastructure services, which are application agnostic and provide common utility functions; (ii) business services, which encapsulate reusable business capabilities; and (iii) healthcare-specific task services, which accomplish specific tasks, often through the orchestration of business services. Potential infrastructure service capabilities include access and security control, event logging, notification, and exception handling. In addition, potential business service capabilities include entity identity resolution, terminology management, patient registration, resource scheduling and management, clinical documentation and data storage, data retrieval, order placement, order fulfillment, billing, and patient-level inferencing. Moreover, potential task service capabilities include aggregating and presenting data within health information systems; generating business intelligence reports for organizational leaders; and providing chronic disease management services to healthcare providers. To date, HSSP has focused on infrastructure services with requirements unique to healthcare (e.g., access and security control services) and business services with significant potential for reuse (e.g., data management and analysis services). Moreover, HSSP focuses on services for which there is both a community demand for standardization and a committed team for leading the standardization effort, an approach that fosters activity in areas of applied industry need and business relevance. While the standard services that HSSP defines over the near term will only represent a portion of potential services, a SOA can support incremental addition of other standard service interfaces as they are developed. The definition of standard SOA interfaces is the primary focus of HSSP and this manuscript. However, HSSP recognizes that an effective SOA requires more than well-defined services; it requires effective coordination, use, and monitoring of these services. For example, healthcare organizations adopting a SOA must support robust audit trails; support high levels of concurrency, load balancing, and failure recovery; and incorporate testing and debugging procedures that account for the possibility that a system leveraging multiple services may fail even when component services are working properly. To address these needs, HSSP provides a Practical Guide on how to leverage HSSP-defined services within an overall SOA strategy. Moreover, one of the authors has previously outlined how HSSP services could be leveraged to fulfill the strategic objectives of the United States Roadmap for National Action on Clinical Decision Support. Design Principles The SSF incorporates design principles that are accepted as industry standard practices. Table 1 describes these principles and how HSSP services fulfill these principles. Leveraging Prior Work The HSSP leverages relevant prior work where appropriate. Leveraged resources include the standards development processes of HL7 and OMG, including the HL7 Development Framework and OMG’s Model-Driven Architecture. Furthermore, infrastructure standards such as the Web Services Description Language, XML Web services, and UML are used as the foundation of service specifications. Service semantics are specified using standard terminologies and information models, such as SNOMED CT® (Copenhagen, Denmark), LOINC® (Indianapolis, IN), HL7 information models, OpenEHR archetypes, and ASTM International’s Continuity of Care Record model. As appropriate, HSSP service specifications explicitly identify their relationships to relevant existing industry work. Approach to Semantics Overview and Rationale The HSSP defines services using coarse-grained, generalized interfaces that leverage constructs called semantic signifiers and semantic profiles to constrain payload semantics. This approach was taken for several reasons. First, this approach allows common interfaces to serve multiple semantic needs. Second, no universal consensus exists on the best information models to use for all aspects of healthcare. Third, preferred healthcare semantics have changed over time and are likely to continue to evolve. Finally, key stakeholders (e.g., the United States Veterans Health Administration) had internally specified semantics that were based on standards riented 876 Kawamoto et al., Standard SOA Services for Healthcare by gest on Jauary 5, 2016 ht://jam ia.oxfournals.org/ D ow nladed from but were not recognized standards themselves. To promote the durability of the specifications under these circumstances, a decision was made to bind semantics to services at the level of service profiles rather than at the level of the core service definition. This approach allows organizations with unique semantic requirements to use HSSP services, while still enabling the use of consensus semantics across organizations should such consensus exist. Semantic Signifiers In HSSP services, a semantic signifier is the manifestation of a computable information model, tagged with a name and version and capable of being used and enforced by reference. Within XML Web service implementations, the information model of a semantic signifier can be defined by an XML Schema Definition and optional Schematron rulebased constraints. Information models that can be referenced via semantic signifiers include HL7 version 2 and version 3 information models. Terminology can be bound to these information models directly in the schema definition. Also, rule-based constraints can be applied to constrain the allowed terminology within model elements. For example, consider the HSSP Retrieve, Locate, and Update Service (RLUS), which may be used to locate, retrieve, and update patient data. In this example, an RLUS client desires a patient’s most recent serum creatinine data, communicated using LOINC codes and HL7 version 3 semantics for laboratory results. To obtain the desired data using the RLUS capability for data retrieval, the client provides the following inputs: (i) the semantic signifier denoting the information model to be used to return the data (the HL7 version 3 information model for laboratory test results, constrained to use LOINC codes); (ii) the semantic signifier denoting the information model used to express query parameters (the HL7 query model associated with the laboratory data model); and (iii) the query parameters represented in the above format, where PatientID the patient identifier and ObserTable 1 y SOA Design Principles and Application wi Design Principle Description Standardization similar services should use standardized service interfaces Loose coupling services should be as independent as possible from other services and from client applications Abstraction information that is not needed by a client to use a service is hidden from the client Reusability services should be context-agnostic and be reusable across diverse use scenarios Autonomy services should exercise significant control over their execution environment Statelessness services should minimize the need to maintain state information across interactions Discoverability services should provide appropriate metadata for discovering available capabilities Composability systems should be able to effectively leverage the service as a system component HSSP Healthcare Services Specification Project; SOA service-o vationType.value LOINC codes for serum creatinine. Semantic Profiles Semantic profiles provide a mechanism for restricting the semantics allowed within HSSP services. Typically, a semantic profile will define which semantic signifiers—and therefore which information models—can be used as input and output parameters within specific service operations. For example, an RLUS semantic profile may require that the information models used in the example above be supported for retrieving laboratory tests results. Framework Formulation Process Following the launching of HSSP in March 2005, the SSF was developed in an open, interactive, and peer-reviewed manner by members of the HL7 SOA Working Group and the OMG Healthcare Domain Task Force through regular teleconferences and face-to-face meetings. Moreover, relevant expertise from the wider HL7 and OMG community was obtained through joint sessions with other committees and well-attended general information sessions. A working draft of the SSF was completed within several months. Since then, the SSF has served as the framework for developing HSSP service specifications, and lessons learned have continually been fed back into the SSF. The SSF therefore represents a stable but continually improving framework for developing service interface standards for healthcare. In the remainder of this manuscript, we describe the SSF and illustrate its use in the specification of interface standards for two healthcare services. Framework Description Overview The SSF delineates a multistep framework in which HL7 defines the functional requirements for healthcare services in Service Functional Models (SFMs) and OMG defines derivative technical specifications. The SSF, as with all HSSP work products, is available on the HSSP Web page. This HSSP Services Application Within HSSP Services purpose of all HSSP service specifications is to standardize rvice interfaces across implementations P services are designed to allow for efficient coordinated use. owever, there are no formal dependencies among HSSP services. P services hide unnecessary implementation details, such as the rogramming language and database structures used P service specifications are designed using diverse use scenarios, help ensure usability across multiple deployment contexts P services are defined within well-demarcated, self-contained nctional boundaries amenable to significant control by service plementations P services are stateless whenever possible. Intermediate state formation is passed back to the client if needed for a future teraction. P services provide metadata that describe their capabilities, cluding semantic profiles and semantic signifiers supported by e service P services are designed to be well-defined, functionally complete, d independent services that can be effectively leveraged as mponents of larger systems